Inconsistency-tolerant business rules in distributed information systems

The final publication is available at Springer via http://10.1007/978-3-642-41033-8_41Business rules enhance the integrity of information systems. However, their maintenance does not scale up easily to distributed systems with concurrent transactions. To a large extent, that is due to two problematic exigencies: the postulates of total and isolated business rule satisfaction. For overcoming these problems, we outline a measure-based inconsistency-tolerant approach to business rules maintenance.Supported by ERDF/FEDER and MEC grants TIN2009-14460-C03, TIN2010-17139, TIN2012-37719-C03-01.Decker, H.; Muñoz Escoí, FD. (2013). Inconsistency-tolerant business rules in distributed information systems. En On the Move to Meaningful Internet Systems: OTM 2013 Workshops. Springer Verlag (Germany). 8186:322-331. https://doi.org/10.1007/978-3-642-41033-8_41S3223318186Abiteboul, S., Hull, R., Vianu, V.: Foundations of Databases. Addison-Wesley (1995)Berenson, H., Bernstein, P., Gray, J., Melton, J., O’Neil, E., O’Neil, P.: A critique of ANSI SQL isolation levels. In: Proc. SIGMOD 1995, pp. 1–10. ACM Press (1995)Bernstein, P., Hadzilacos, V., Goodman, N.: Concurrency Control and Recovery in Database Systems. Addison-Wesley (1987)Butleris, R., Kapocius, K.: The Business Rules Repository for Information Systems Design. In: Proc. 6th ADBIS, vol. 2, pp. 64–77. Slovak Univ. of Technology, Bratislava (2002)Davis, C.T.: Data Processing sphere of control. IBM Systems Journal 17(2), 179–198 (1978)Decker, H.: Partial Repairs that Tolerante Inconsistency. In: Eder, J., Bielikova, M., Tjoa, A.M. (eds.) ADBIS 2011. LNCS, vol. 6909, pp. 389–400. Springer, Heidelberg (2011)Decker, H.: Causes of the violation of integrity constraints for supporting the quality of databases. In: Murgante, B., Gervasi, O., Iglesias, A., Taniar, D., Apduhan, B.O. (eds.) ICCSA 2011, Part V. LNCS, vol. 6786, pp. 283–292. Springer, Heidelberg (2011)Decker, H.: New measures for maintaining the quality of databases. In: Murgante, B., Gervasi, O., Misra, S., Nedjah, N., Rocha, A.M.A.C., Taniar, D., Apduhan, B.O. (eds.) ICCSA 2012, Part IV. LNCS, vol. 7336, pp. 170–185. Springer, Heidelberg (2012)Decker, H.: Controlling the Consistency of the Evolution of Database Systems. In: Proc. 24th ICSSEA, Paris (2012)Decker, H., Martinenghi, D.: Inconsistency-tolerant Integrity Checking. IEEE Transactions on Knowledge and Data Engineering 23(2), 218–234 (2011)Decker, H., Muñoz-Escoí, F.D.: Revisiting and Improving a Result on Integrity Preservation by Concurrent Transactions. In: Meersman, R., Dillon, T., Herrero, P. (eds.) OTM 2010 Workshops. LNCS, vol. 6428, pp. 297–306. Springer, Heidelberg (2010)Eswaran, K., Gray, J., Lorie, R., Traiger, I.: The Notions of Consistency and Predicate Locks in a Database System. CACM 19(11), 624–633 (1976)Gilbert, S., Lynch, N.: Brewer’s Conjecture and the feasibility of Consistent, Available, Partition-tolerant Web Services. ACM SIGACT News 33(2), 51–59 (2002)Ibrahim, H.: Checking Integrity Constraints - How it Differs in Centralized, Distributed and Parallel Databases. In: Proc. 17th DEXA Workshops, pp. 563–568. IEEE (2006)Lynch, N., Blaustein, B., Siegel, M.: Correctness Conditions for Highly Available Replicated Databases. In: Proc. 5th PODC, pp. 11–28. ACM Press (1986)Martinenghi, D., Christiansen, H.: Transaction Management with Integrity Checking. In: Andersen, K.V., Debenham, J., Wagner, R. (eds.) DEXA 2005. LNCS, vol. 3588, pp. 606–615. Springer, Heidelberg (2005)Christiansen, H., Decker, H.: Integrity checking and maintenance in relational and deductive databases and beyond. In: Ma, Z. (ed.) Intelligent Databases: Technologies and Applications, pp. 238–285. Idea Group (2006)Morgan, T.: Business Rules and Information Systems - Aligning IT with Business Goals. Addison-Wesley (2002)Muñoz-Escoí, F.D., Ruiz-Fuertes, M.I., Decker, H., Armendáriz-Íñigo, J.E., de Mendívil, J.R.G.: Extending Middleware Protocols for Database Replication with Integrity Support. In: Meersman, R., Tari, Z. (eds.) OTM 2008, Part I. LNCS, vol. 5331, pp. 607–624. Springer, Heidelberg (2008)Nicolas, J.-M.: Logic for improving integrity checking in relational data bases. Acta Informatica 18, 227–253 (1982)Novakovic, I., Deletic, V.: Structuring of Business Rules in Information System Design and Architecture. Facta Universitatis Nis, Ser. Elec. Energ. 22(3), 305–312 (2009)Pipino, L., Lee, Y., Yang, R.: Data Quality Assessment. CACM 45(4), 211–218 (2002)Stonebraker, M.: Errors in Database Systems, Eventual Consistency, and the CAP Theorem (2010), http://cacm.acm.org/blog/blog-cacm/83396-errors-in-database-systems-eventual-consistency-and-the-cap-theoremStonebraker, M.: In search of database consistency. CACM 53(10), 8–9 (2010)Stonebraker, M.: Technical perspective - One size fits all: an idea whose time has come and gone. Commun. ACM 51(12), 76 (2008)Taveter, K.: Business Rules’ Approach to the Modelling, Design and Implementation of Agent-Oriented Information Systems. In: Proc. CAiSE workshop AOIS, Heidelberg (1999)Vidyasankar, K.: Serializability. In: Liu, L., Özu, T. (eds.) Encyclopedia of Database Systems, pp. 2626–2632. Springer (2009)Weikum, G., Vossen, G.: Transactional Information Systems. Morgan Kaufmann (2002)Vogels, W.: Eventually Consistent. ACM Queue 6(6), 14–19 (2008)Pereira Ziwich, P., Procpio Duarte, E., Pessoa Albini, L.: Distributed Integrity Checking for Systems with Replicated Data. In: Proc. ICPADS, vol. 1, pp. 363–369. IEEE CSP (2005

Node.js: Module management

Node.js es un intérprete JavaScript que puede utilizarse desde la línea de órdenes en la mayoría de los sistemas operativos actuales. Este objeto de aprendizaje describe qué es un módulo en Node.js, cómo se puede importar uno o más módulos en nuestros programas y cómo podemos definir nuestros propios módulos. La notación necesaria para ello todavía no sigue el estándar ECMAScript 6, sino la sugerida en CommonJS.https://polimedia.upv.es/visor/?id=5ffbe6d0-cbfd-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). Node.js: Module management. Universitat Politècnica de València. http://hdl.handle.net/10251/168460DE

ZeroMQ: PUB-SUB pattern

La biblioteca ZeroMQ proporciona soporte para múltiples tipos de "socket". Esos tipos permiten definir algunos patrones de comunicación con propiedades interesantes a la hora de optimizar el rendimiento de los servicios distribuidos. Uno de esos patrones combina los "sockets" PUB y SUB para definir un canal de comunicación unidireccional asincrónico con capacidad de difusión de mensajes a múltiples destinatarios. Este objeto de aprendizaje describe ese patrón PUB/SUB, analizando sus principales ventajas e inconvenientes.https://polimedia.upv.es/visor/?id=c951c950-cc03-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). ZeroMQ: PUB-SUB pattern. Universitat Politècnica de València. http://hdl.handle.net/10251/168505DE

Node.js: Module 'events'

Node.js incluye una amplia colección de módulos que se instalan conjuntamente con su intérprete. El módulo 'events' forma parte de esa colección y permite a las aplicaciones desarrolladas en Node.js emitir y gestionar eventos de una manera sencilla. Los eventos proporcionan la base necesaria para implantar aplicaciones asincrónicas. Este módulo de aprendizaje describe la funcionalidad de este módulo y explica cómo debe importarse. También describe las dos operaciones más importantes en la gestión de eventos: cómo emitir un evento de manera explícita y cómo asociar una función que pueda gestionar la llegada de cada evento (un "listener"). Por último, estos conceptos se aplican en un programa breve cuya ejecución se analiza en detalle.https://polimedia.upv.es/visor/?id=a11da360-cbfd-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). Node.js: Module 'events'. http://hdl.handle.net/10251/168497DE

JavaScript: the turn queue

Este objeto describe la gestión de actividades en el lenguaje de programación JavaScript. Para ello se propone el concepto de "cola de turnos" en la que se irán acumulando los nuevos eventos que vayan ocurriendo.https://polimedia.upv.es/visor/?id=7af0f0d0-df15-11eb-a546-272bd5a56a56Muñoz Escoí, FD. (2021). JavaScript: the turn queue. Universitat Politècnica de València. http://hdl.handle.net/10251/168962DE

Passive replication

Este objeto describe el modelo de replicación pasivo, explicando la secuencia de pasos utilizada en este modelo para procesar una solicitud de un proceso cliente. Se menciona cuáles son las ventajas aportadas por este tipo de replicación, así como los inconvenientes que comporta en algunas situaciones. Por último, también se esboza el grado de consistencia que puede proporcionar entre los procesos servidores que utilicen este modelo.https://polimedia.upv.es/visor/?id=d96cce50-cccd-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). Passive replication. Universitat Politècnica de València. http://hdl.handle.net/10251/168223DE

LAMP systems

Este objeto describe qué es un sistema LAMP. Para ello, explica qué componentes intervienen en un sistema de este tipo, sus interacciones y qué posibilidades ofrecen para mejorar su rendimiento y su disponibilidad.https://polimedia.upv.es/visor/?id=77e10490-cbeb-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). LAMP systems. http://hdl.handle.net/10251/168503DE

Active replication

Este objeto de aprendizaje presenta el modelo de replicación activo. Para ello, describe la secuencia de pasos utilizada en este modelo para procesar una petición de un proceso cliente, indicando cómo las réplicas servidoras gestionan esa solicitud y proporcionan respuesta al solicitante. El objeto también explica las ventajas e inconvenientes que ofrece esta gestión.https://polimedia.upv.es/visor/?id=0c2349f0-ccce-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). Active replication. Universitat Politècnica de València. http://hdl.handle.net/10251/168355DE

ZeroMQ: ROUTER socket

La biblioteca ZeroMQ proporciona un conjunto amplio de tipos de "socket". La mayoría de esos tipos ofrecen soporte para comunicación asincrónica y con ello permiten mejorar el rendimiento de los servicios distribuidos que los utilicen. Uno de esos tipos de "socket" es el ROUTER. Los "sockets" de tipo ROUTER han sido diseñados para ser utilizados en los procesos servidores, implantando con ellos comunicación bidireccional asincrónica. Así, se permite que un determinado servidor pueda atender a múltiples procesos clientes, que a su vez utilizarán "sockets" de tipo DEALER. Para que el servidor pueda enviar la respuesta al cliente adecuado, los "sockets" ROUTER asignan internamente un identificador a cada conexión. No obstante, la asignación de identidad puede realizarse también de manera explícita utilizando una propiedad (concretamente, la propiedad "identity") de los "sockets" que se conecten al ROUTER. Este objeto de aprendizaje describe las principales características de los sockets ROUTER. Su funcionalidad se describe en un ejemplo breve en el que interactúa con clientes que utilizan "sockets" de tipo REQ, pues ese tipo de interacción resulta algo más difícil que la establecida en un canal DEALER-ROUTER.https://polimedia.upv.es/visor/?id=ce037510-cc04-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). ZeroMQ: ROUTER socket. Universitat Politècnica de València. http://hdl.handle.net/10251/168455DE

Causal consistency

Este objeto presenta el modelo de consistencia causal, basado en la relación "ocurre antes" (definida por Leslie Lamport). En la presentación se define el modelo y se describe un ejemplo de ejecución que respeta este modelo de consistencia, para reforzar qué condiciones deben cumplir estas ejecuciones.https://polimedia.upv.es/visor/?id=260dbd80-ccd0-11ea-b9aa-fb17ac3de2a0Muñoz Escoí, FD. (2021). Causal consistency. Universitat Politècnica de València. http://hdl.handle.net/10251/168354DE